A business organization usually keeps and manages its business information using software applications which are commonly referred to as Business Applications. The data of a Business Application is usually stored in a database and is organized in a number of entities. An entity is a structure for storing data, where the data within the structure is typically grouped together on the basis of some common characteristics. For example, a Purchasing Application may keep data about trading partners, purchasing orders, shipments, invoices, and inventory. Thus, the Purchasing Application may have separate entities for storing data about the Trading Partners, the Purchasing Orders, the Shipments, the Invoices, and the Inventory. Different Business Applications are developed at different points in time by different software makers, and thus entities for storing the same data are usually different in the different Business Applications.
Data that is transferred between Business Applications is usually transferred in the form of well-defined electronic documents. Typically, different industries will define different standards for electronic documents. For example, the manufacturing industry adheres to Open Applications Group standards, and the semi-conductor and telecom industries adhere to RosettaNet standards. However, since different Business Applications, supported by different databases, store data in different entities, a problem arises when entity data from one Business Application needs to be stored in a standard electronic document that can be transferred to another Business Application. The same problem arises when data from an electronic document needs to be stored (or consumed) in the entities of a Business Application. The problem is further exacerbated because of the differences in how an entity is structurally represented in the various databases and in the various electronic documents. Furthermore, an entity used by one Business Application may be represented by two or more entities in another Business Application, which will create even more difficulties when the data from the entity needs to be stored into or retrieved from an electronic document governed by a particular standard.
One approach to solve the problem is the “hard-coding” approach. Under this approach a programming language is used to write a computer program. The computer program will store in its code all the necessary information to extract data from specific entities to generate electronic documents, or to store external data from electronic documents into specific entities. In either case, the computer program will contain all the information about the structure of the particular electronic document to which data is to be written or from which data is to be read. It is apparent that this approach is very labor-intensive and cost-ineffective, especially when a Business Application has a large number of entities and needs to write to or read from a large number of differently-structured electronic documents. Furthermore, since Business Applications evolve, from time to time entities may be changed and thus the computer program must be modified to accommodate these changes. Similarly, the standards governing the structure of the electronic documents may also change which will require corresponding changes in the computer program.
Another approach to solving the problem is the “canonical format” approach. Under this approach, the data from selected entities is first stored into a second set of entities. In the second set of entities the data is arranged in a predefined fixed format (i.e. a canonical format). Once the data is stored in canonical format, a second set of transformations is performed on the data to convert it into an electronic document governed by a particular standard. The second set of transformations is essential under this approach since the standard electronic document may or may not fully support the predefined canonical format. One implementation of this approach may include using XSQL to transform the data to the canonical format. XSQL is the combination of the XML (Extensible Markup Language) and the SQL (Structured Query Language) to provide a language and means to store and retrieve data from the database entities.
One issue with the canonical format approach is that it requires at least two sets of data transformations to create a standard electronic document. Specifically, it requires one transformation from the original data format to the canonical format, and a second transformation from the canonical format to the format of the target electronic document. This issue is particularly acute when a large amount of data needs to be converted to an electronic document because processing a large amount of data at least twice may consume a lot of computing resources (such as computer memory, processor time, etc.). Another issue with the canonical format approach is that is very inflexible. The standards governing the electronic documents evolve and change with time, and in order to fully support standard electronic documents, the programming language (such as XSQL) used to transform data into the canonical format must also evolve and change.
Based on the forgoing, it is desirable to provide a flexible mechanism through which data from entities in a Business Application is efficiently converted to electronic documents governed by particular standards, and through which data from electronic documents governed by particular standards are stored in the entities of a Business Application.
Entities can be represented in a variety of ways in Business Applications and in electronic documents. For example, in a Business Application supported by a relational database, an entity can be represented as a table, or a set of tables, having columns, each column being able to hold data of a particular data type. On the other hand, electronic documents can use different elements to represent an entity. For example, in an electronic document in the XML format, an entity can be represented as a node containing elements, the elements further containing attributes.
Systems that implement the present invention, however, are not limited to any particular type of entity, any particular type of database, any particular type of a Business Application, or any particular type of electronic document. For the purpose of explanation, all the elements, properties, and characteristics representing and describing an entity, in an electronic document or in a Business Application (and its supporting database), will be hereafter referred to as attributes. Furthermore, an electronic document or a database (along with the Business Application it supports) which contains the entities with the data will be hereafter referred to as a source. Similarly, an electronic document or a database (along with the Business Application it supports) which is to receive data in its entities will be hereafter referred to as a target.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.